feat(results): expose Tekton Results Watcher config via TektonConfig#3709
feat(results): expose Tekton Results Watcher config via TektonConfig#3709adchauha wants to merge 4 commits into
Conversation
Add spec.result.watcher so watcher flags can be configured through TektonConfig without manually patching tekton-results-watcher Deployment args.
|
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/kind feature |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3709 +/- ##
==========================================
- Coverage 25.51% 25.47% -0.05%
==========================================
Files 448 449 +1
Lines 23309 23372 +63
==========================================
+ Hits 5948 5954 +6
- Misses 16675 16726 +51
- Partials 686 692 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
enarha
left a comment
There was a problem hiding this comment.
The idea of storing the watcher configuration under .result.watcher is good.
The watcher has 21 configuration options (https://github.com/tektoncd/results/blob/main/cmd/watcher/main.go#L64-L85) , but here I see exposed only 15. Was that done on purpose and what's the criteria to decide which flags are exposed through the TektonConfig and which not?
I believe that as implemented, the new flags will be set on new deployment, but if user changes the TektonConfig later, the configuration on the cluster won't be updated. Can you please test that scenario and ensure it works? Updating the TektonConfig should always trigger reconciliation and new configuration should take an effect immediately.
Sync Watcher on TektonConfig updates, hash pod labels for free-text values, safely replace two-form container args, validate watcher on TektonConfig, and expand unit tests. Signed-off-by: adchauha <adchauha@redhat.com>
It is intentional. Under spec.result.watcher we expose user-facing behavior flags (grace period, store deadline, selectors, timeouts, etc.). Performance knobs (threadiness/qps/burst/disable-ha) already live under spec.result.performance. Connection/install wiring (api_addr, auth_mode) comes from the Results manifest. Token must not live in the CR, use Secrets. Documented in docs/TektonConfig.md / ResultsWatcherProperties. UpdateResult synced Performance/Options but not Watcher, so later TektonConfig edits could be ignored. Fixed by syncing Spec.Watcher the same way, plus TestUpdateResult_WatcherPropagation. Updating TektonConfig watcher fields now reconciles through to the live Deployment. |
Allow clearing watcher text defaults via empty string pointers, and correctly replace two-element args whose value starts with '-' (e.g. -completed_run_grace_period -1h). Signed-off-by: adchauha <adchauha@redhat.com>
Add spec.result.watcher so watcher flags can be configured through TektonConfig without manually patching tekton-results-watcher Deployment args.
Changes
ResultsWatcherPropertiesandspec.result.watcherto TektonConfig and TektonResult CRDstekton-results-watcherDeployment container args viaUpdateWatcherFlagsInDeploymentdocs/TektonConfig.mdanddocs/TektonResult.mdWatcher flags exposed include:
completed_run_grace_periodcheck_ownerstore_deadlinedisable_storing_incomplete_runslogs_api,logs_timestamps,store_eventsummary_labels,summary_annotations,label_selectorrequeue_interval,forward_buffer,update_log_timeout,dynamic_reconcile_timeout,disable_crd_updateSubmitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
make test lintbefore submitting a PRSee the contribution guide for more details.
Release Notes